Microsoft Lync Server 2010 : Planning for Deploying External Services - High Availability

DNS load balancing seems like an attractive feature at first, but does have some limitations. Organizations should review these limitations and then make a decision about whether a hardware load balancer is required. The main limitation of DNS load balancing is that it does not work with some features or legacy endpoints, including

Endpoints running previous versions of the Communicator client

Federated organizations running previous versions of Communications Server

• Public IM connectivity

• XMPP Gateway

• Exchange Server 2007 and 2010 RTM Unified Messaging Signaling and Audio

• Exchange Server 2010 SP1 Unified Messaging for Audio

Not all organizations are affected by these limitations and might still be able to deploy DNS load balancing for their Lync Server infrastructure.

Hardware Load Balancer

Using a hardware load balancer comes at a greater cost than DNS load balancing, but adds some flexibility and backward compatibility that an organization might require. Configuring the hardware load balancer is typically the most difficult part of an Edge Server deployment simply because of how flexible the load-balancing software generally is.

Some basic guidelines must be followed when using a hardware load balancer for Edge services:

• Each external-facing Edge service needs a publicly routable virtual IP address.

• Each Edge Server needs three publicly routable IP addresses assigned.

To summarize the requirements, if an organization deploys two Edge Servers with a hardware load balancer, it needs nine publicly routable IP addresses: three for the virtual IP addresses and three for each Edge Server. That logical configuration is depicted in Figure 1.

Figure 1. Hardware Load Balancer VIPs and Edge Server Real IP Addresses

In addition to the public IP addressing requirements, there are some stipulations about what type of Network Address Translation (NAT) must be configured on the load balancer. For traffic from the Internet to the server, the hardware load balancer must use Destination Network Address Translation (DNAT).

This means that as a packet is received from the Internet to the virtual IP address, the hardware load balancer rewrites the packet to change the destination IP address to one of the IP addresses actually assigned to an Edge Server network adapter.

For traffic from the server to the Internet, the load balancer must be configured for Source Network Address Translation (SNAT). This means that packets sent outbound from the Edge Servers are translated by the load balancer back to the virtual IP address that the external Internet clients expect to communicate with.

Hardware Load Balancer Configuration

This section discusses the hardware load balancer configuration for an Edge Server. There are two perspectives to look at for load balancing Edge Servers because the external-facing adapter and internal-facing adapter have their own requirements. An Edge Server must be load balanced on both sides to function properly, but each side has slightly different requirements.

Starting with the external interfaces, the load balancer should have three publicly routable virtual IP (VIP) addresses: one for the Access Edge, one for the Web Conferencing Edge, and one for the A/V Edge. These three virtual IP addresses map to the three public IP addresses configured on each Edge Server. So, the VIP used for Access Edge maps to the real IP addresses for each Edge Server’s Access Edge service, and the same goes for the Web Conferencing Edge and A/V Edge services. Depending on the load balancer configuration, this usually requires three separate pool objects, as depicted in Figure 2.

Figure 2. Edge Server Load-Balanced Ports

Table 1 outlines what ports must be load balanced to each virtual IP address.

After configuring the external interface load balancing, the internal adapter configuration must be completed. Unlike the external adapter that uses three virtual IP addresses, only a single virtual IP address is required for the internal adapter because each Edge Server has only a single IP address for its internal adapter.

Table 2 outlines what ports must be load balanced to each virtual IP address.

DNS Load Balancing

If the limitations of DNS load balancing described earlier don’t pose any issues to an organization’s Lync Server deployment, the organization can proceed with that method instead of purchasing a hardware load balancer. There are actually some advantages to using DNS load balancing, mainly the simplicity involved in configuring the load balancing that just involves using multiple A records for the same name in public DNS. Table 3 shows the DNS records required to achieve DNS load balancing.

When using DNS load balancing, the Edge Server can use private IP addresses that are translated by NAT for all three roles including A/V Edge. This is a big advantage for organizations that might not have many public IP addresses available because when using DNS load balancing, there is no virtual IP address requirement.

In other words, DNS-based load balancing requires three fewer IP addresses than a hardware load-balancing solution. Each Edge Server IP still needs to be mapped to a unique public IP address if it is being translated by NAT, but there is no idea of a virtual IP address in this type of solution. In fact, when using DNS load balancing, Microsoft recommends using NAT for the IP addresses bound to the Edge Server network adapters.

Another advantage of DNS load balancing is that the native server-draining feature in Lync Server is available. This enables administrators to prepare a server by maintenance through the Lync Server Control Panel the same way as the other roles.

In some organizations, the team responsible for Lync Server might not be the same team that manages the network and hardware load balancers, which can make it difficult to coordinate preparing a server for maintenance. Instead of the Lync Server administrators quickly draining a server’s connections, they might need to submit a request to have the network team drain the load balancer connections for a particular node and then check back later to determine whether the connections have cleared.

Sometimes this separation of teams can be just as efficient as one person having complete control, but often times it slows down the maintenance process.